「BigQuery 是什麼？大數據時代一定要認識的最強資料分析工具」—— 搜尋 BigQuery 時的第一個網頁。
BigQuery 的功能實在強大，資料存儲、運算，支援的資料類型與操作極其多元，後端可以輕鬆地把資料送過來，所有資料使用者也都可以簡單地使用 SQL 程式碼取得自己需要的資料。並且它還不斷地在擴張宇宙，想要統合機器學習、GAI 等功能，甚至可以在裡面寫 python。
如果大家看了前一篇中 dbt 導入前與導入後的架構圖，可以知道 dbt 在我們的資料架構中取代的是：
原始資料匯入 BigQuery 後，原先透過 procedures 來做轉換，現在改用 dbt models 來做轉換。dbt 是從 ETL 轉型為 ELT 之後，擔當最後 Transform 要角的工具。
因此這篇我想來談談，明明都是以 SQL 為基礎的工具，原先用 BigQuery procedures 來做轉換遇到了什麼樣的限制跟痛點，才會痛到我們走出了大 BigQuery，接納一套新工具來幫助我們進行轉換工作。
BigQuery 功能強大，大家都想把所有的 data 跟 procedure 資料存進去，然而它的資料集結構增加了管理難度，它只支援單層資料集，無法建立層級化的子資料集，人人都可以因應不同業務需求，來建立資料集存放資料，過度扁平的資料架構，會讓資料混雜在整資料庫中，管理跟易用性都充滿挑戰。
舉例來說，我們就算參考 dbt 的原則，建立了 staging, mart 等資料集來管理，然而還是有很多不同的資料來源、數十個專案、所有使用者的個人資料集，會讓你在使用時非常茫然，並且在 staging, mart 等資料集中，也沒辦法有更細的子分類來做管理。
像是我們現在就有五六十個資料集，若是對資料庫沒有足夠的熟悉度（待得還不夠久），就常得要打開資料集，一張一張表點開看表名跟欄位是否是自己需要的。
即使是 SQL 程式碼，版本控制也是蠻基本的操作，我們確實有將程式碼推上 git 做版本控制，但其實是非同步在進行的，什麼意思呢？
我們在 BigQuery 的界面上編輯 SQL 程式碼，建立好 procedure、確認沒有問題後，將程式碼推上 git。
這會發生什麼問題呢？
當今天業務單位發現資料有問題，我們趕緊在 BigQuery 調整部署後，危機解除，皆大歡喜。然後就跟業務單位回報我們已經將問題解決，快樂休息。
結果就忘記把調整後的程式碼推上 git 做版本控制了 XD
我們有幾百隻程式碼，而其中許多程式碼都有上下游關係，我們透過 airflow 排程時，需要進入每隻程式碼中檢查他們的上下游，編寫任務間的依賴關係。
這件事情使得 procedure 與 airflow 有高度耦合的關係，編寫 procedure 的同時，還要去更新 airflow 的任務排程。
想像一個實際情況，業務單位今天提出需求說：有五張表希望從週更變成日更。
這時候我們就要去看目前排程任務，把這五張表從周更的任務搬移至日更任務中，調整一下依賴關係。當你覺得這樣就迅速完成時，隔天的 pipeline 就噴了一堆錯誤，因為這五張表中，有幾張表的上游資料沒有在日更的任務中。
每次要調整一張表時，就要綜觀整條 pipeline，確認它的上下游更新的時間是否符合預期，就是我們遇到的痛點。
要讓資料足夠透明、讓資料使用者能迅速理解資料與信任資料，做好資料治理，進而達到 data contract 的層次，文件跟測試絕對是重中之重。
我們將資料表紀錄了哪些資訊、以及每個欄位的意義，紀錄在其他的文件管理工具中，期待能夠對齊大家對於資料的認知，然而相信讀者們肯定沒少遇過文件跟實際情況完全不一致的情形ＸＤ
急急忙忙開發完新的 pipeline 後將其上線，要跟業務單位溝通、還要驗證資料的正確性，「寫文件什麼的實在有夠麻煩，肯定是等有空的時候再寫，反正你要知道什麼資訊，直接來找我聊就對了」。這種心態讓文件跟程式碼有相當程度的脫鉤，債務留給後人承受…
文件不齊全，測試的狀況想必也不難猜，偶爾遇到使用者回報狀況時，寫一段 SQL 來確認是不是有 bug，如果有的話回去修正程式碼，這樣的流程屢見不鮮，其他大神是 test-driven development，我們是 bug-driven development XD
以上記錄幾點我們運用 BigQuery procedure 來做資料轉換時遇到的痛點，接著我們就來談談為何我們認為 dbt 可以幫助我們解決問題。
更重要的是必須釐清：我們想解決的問題，真的沒有辦法用 BigQuery 提供的功能做到嗎？一定要導入新工具？還是只是手癢想要玩新東西？蒐集足夠的論點來說服主管釋放資源讓新專案通行！Go Go！
iThome鐵人賽
看影片追技術